Hierachies in Epics and Visual Dct

Visual DCT [1] (Visual Database Configuration Tool) is becoming the most popular graphical database configuration tool for EPICS [2] databases. EPICS is a widely used control system based on a real-time database configured from text files. The configuration data comes from two types of files one defines templates and the other instantiates channels from them. The current EPICS template substitution mechanism [3] is restricted in its capabilities and it only allows macros to be passed downwards into a template instance. This limitation makes an EPICS database totally flat, which can result in great difficulties when designing complex applications, not to mention maintaining them. The next release of EPICS will introduce hierarchy support into EPICS core. Instruments will be provided for templates to export fields that are of public interest and thus resembling mechanisms of object-oriented programming. However, this release may still be some time away, while developers need those features now. The present version of Visual DCT therefore has full graphical support for hierarchical features, enabling developers of today to use the technology of tomorrow. VDCT leads the field in advanced features, such as reverse engineering of already existing databases, and user friendliness. It is also the only graphical database configuration tool, which not only supports hierarchies in the EPICS databases now, but also incorporates an integral Database Flattening Tool to produce EPICS databases to be compatible with and executable on current core releases. New development will also introduce debug tools allowing real-time display of channel properties inside Visual DCT, making database debugging much easier. EPICS AND HIERARCHIES Abstraction of certain algorithms and grouping functions to make logical blocks have helped computer programming immensely. Only by using these approaches can a programmer of today cope with the complexity of modern programs, understanding those thousands of lines of source code. EPICS core so far has no support of hierarchical programming. Developers worldwide use different approaches how to cope with complex EPICS databases. Up until now the best tool to use was CapFast [4], which is a commercial tool for making electronic drawings, adapted to support EPICS databases as well. The main disadvantage of CapFast is its price, which is considerably high, especially for mostly academically based EPICS community. Developed for a different purpose, CapFast is not optimized for EPICS databases as well. HIERARCHIES AS A PART OF EPICSion of certain algorithms and grouping functions to make logical blocks have helped computer programming immensely. Only by using these approaches can a programmer of today cope with the complexity of modern programs, understanding those thousands of lines of source code. EPICS core so far has no support of hierarchical programming. Developers worldwide use different approaches how to cope with complex EPICS databases. Up until now the best tool to use was CapFast [4], which is a commercial tool for making electronic drawings, adapted to support EPICS databases as well. The main disadvantage of CapFast is its price, which is considerably high, especially for mostly academically based EPICS community. Developed for a different purpose, CapFast is not optimized for EPICS databases as well. HIERARCHIES AS A PART OF EPICS EPICS community understands the problem and lack of hierarchical designs inside EPICS databases. The next major release of EPICS core will therefore include support for hierarchical designs. This calls for additional keywords in the EPICS database syntax. So far, there were two types of file associated with EPICS databases. First, we had a template file in which the database was actually “programmed” and a substitution file which was able to create multiple instances of templates, filling macros with appropriate values. The new proposal allows for a two-way communication among different templates. This includes passing down macros into the template instance (giving values for fields within expanded template) and values to be exported from the template instance to the higher level (usually the destination field name for a link in a record defined in the higher level file). Macros are defined in the expand statement and pass information into a template; ports are a kind of macros defined in a template statement that pass information upwards out of a template instance to their calling database. record(calc,"slide1:error") { field(INPA,"$(slmot1.position)")